Techniques for virtualization as interprocess communication, synchronization and code obfuscation

ABSTRACT

Techniques are presented for obfuscating programs of virtual machines. On a virtual machine hosted by a physical device, a program is run that is configured to execute one or more operations. At a virtual machine manager hosted by the physical device and configured to manage the virtual machine, execution of the program is monitored to detect a trapping event that causes the virtual machine manager to take over operation of the program. Upon detecting the trapping event, a specific operation of the program is performed that differs from an operation implied by static analysis of the program.

TECHNICAL FIELD

The present disclosure relates to obfuscating programs running on avirtual machine.

BACKGROUND

A physical computing device may be configured to host software thatexecutes programs and applications. The software may also be configuredto host virtual machines. The virtual machines may be configured to runtheir own operating systems (known as “guest operating systems”) inorder to execute programs and applications that are run by the virtualmachines. Furthermore, the physical computing device may be configuredto host a virtual machine manager (or “hypervisor”) that manages thevirtual machines. In some scenarios, when a program of one or more ofthe virtual machines attempts to perform a certain operation, thevirtual machine manager may take over or “trap” the operation and mayperform or “emulate” the operation. Thus, virtual machine managers aresaid to be able to perform trap-and-emulate operations for programsintended to be run by the virtual machines.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows an example system depicting physical devices that host aplurality of virtual machines and that have code obfuscation software.

FIG. 2 shows an example of trap-and-emulate operations performed by avirtual machine manager in response to an obfuscated trapping event.

FIGS. 3A-3C show example responses from the virtual machine manager inresponse to performing the trap-and-emulate operations.

FIG. 4 shows an example flow chart depicting a sequence of operationsthat trigger the trap-and-emulate operation performed by the virtualmachine manager.

FIG. 5 shows an example block diagram of the physical device withsoftware configured to perform obfuscation techniques.

DESCRIPTION OF EXAMPLE EMBODIMENTS Overview

Techniques are presented for obfuscating programs of virtual machines.On a virtual machine hosted by a physical device, a program is run thatis configured to execute one or more operations. At a virtual machinemanager hosted by the physical device and configured to manage thevirtual machine, execution of the program is monitored to detect anobfuscated trapping event that causes the virtual machine manager totake over operation of the program. Upon detecting the obfuscatedtrapping event, a specific operation of the program is performed.

Example Embodiments

The techniques described hereinafter relate to code obfuscationtechniques of programs in virtual environments. Specifically, in oneexample, the techniques described hereinafter relate to code obfuscationfor programs configured to perform operations on one or more virtualmachines hosted by a physical device. An example system/network(hereinafter “system”) is shown in FIG. 1 at reference numeral 100. Thesystem 100 in FIG. 1 shows a plurality of physical devices102(1)-102(n). The physical devices 102(1)-102(n) are connected to anetwork 104 and are configured to exchange messages with each otheracross the network 104. Each of the physical devices 102(1)-102(n) maybe configured to host one or more virtual machines. For simplicity, FIG.1 shows physical device 102(1) hosting virtual machines 106(1)-106(m),though it should be appreciated that any number of virtual machines maybe hosted by any of the physical devices 102(1)-102(n). The virtualmachines of the physical devices 102(1)-102(n) can also exchangecommunications with each other across the network 104.

In general, the virtual machines 106(1)-106(m) are hosted as a level ofabstraction provided by an operating system of the physical device102(1). That is, the physical device 102(1) may host hardwarecomponents, shown at reference numeral 108, and may also host softwarecomponents stored in memory, shown at reference numeral 110. Memory 110may also store code obfuscation software 107. The software components inthe memory 110 are configured to instruct the hardware components 108(e.g., a computer processor) to perform certain operations. For example,the physical device 102(1) may store in the memory 110 an operatingsystem. The operating system of the physical device 102(1) may containsoftware for one or more programs or applications (hereinafter“programs”) configured to perform specific tasks that are executed bythe hardware components 108 upon proper instruction.

The operating system of the physical device 102(1) may also enableabstraction or emulated processes that may be performed by the physicaldevice 102(1). For example, the operating system may enable abstractionsfor underlying operations of the hardware components 108 themselves(e.g., the operating system may emulate memory components of thephysical device as “virtual memory”). In one example, the operatingsystem may comprise an abstraction that emulates operations of an entirephysical device, including, e.g., abstractions for physical memory,memory management units (e.g., page tables), input/output devices, etc.The abstractions for entire physical devices are known as “virtualmachines.” Just as the physical device 102(1) may run an operatingsystem, the abstraction of a physical device (i.e., a virtual machine)can also run an operating system. Also, as stated above, there may bemultiple abstractions for multiple physical devices, and thus, theoperating system of the physical device 102(1) may run (or “host”)multiple virtual machines simultaneously, as depicted in referencenumerals 106(1)-106(m) in FIG. 1.

Each of the operating systems of the virtual machines 106(1)-106(m) isreferred to as a “guest operating system” or “guest OS.” The guestoperating systems may be different operating systems for each virtualmachine 106(1)-106(m). For example, the guest operating system ofvirtual machine 106(1) may be an iOS™ operating system, the guestoperating system of virtual machine 106(2) may be an Android™ operatingsystem and the guest operating system of virtual machine 106(3) may be aWindows™ operating system. Each of the guest operating systems of thevirtual machines 106(1)-106(m) is configured to run one or more programsor applications. The programs are shown at reference numerals112(1)-112(m) for corresponding virtual machines 106(1)-106(m).

Just as programs of the operating system of the physical device 102(1)may comprise instructions for the hardware components 108 to performcertain operations, the programs 112(1)-112(m) of the virtual machines106(1)-106(m) may similarly comprise instructions for the hardwarecomponents 108 also to perform certain operations. However, at times,the instructions contained within the programs 112(1)-112(m) mayconflict with one another, and as a result, the instructions containedwithin the programs 112(1)-112(m) may attempt to access some of the samehardware components 108 at the same time. In a traditional operatingsystem (i.e., one operating system per physical device), the operatingsystem itself arbitrates access to the hardware components 108. However,when there are multiple operating systems (e.g., multiple guestoperating systems), each guest operating system may believe that it, andit alone, is in charge of the hardware components 108. In this example,the virtual machine manager 114 arbitrates access to the hardwarecomponents 108 between the multiple guest operating systems. In otherwords, when there are multiple operating systems of a physical device,the instructions in the programs 112(1)-112(m) may be attempting toperform normally valid operations, but because the programs are sharingthe same hardware 108, their access needs to be arbitrated by thevirtual machine manager 114. The instructions contained within theprograms 112(1)-112(m) may attempt to access one or more of the hardwarecomponents 108 of the physical device 102(1) that is only accessible viathe operating system of the physical device. In these instances, theguest operating system would normally be the function that performs thearbitration between multiple programs. However, in a virtualizedenvironment, this arbitration is complicated by the fact that severaloperating systems, all believing that they have exclusive access to thehardware, conflict with each other over the shared hardware components108.

In order to address these problems, the operating system of the physicaldevice 102(1) may be configured, in some instances, to “take over”control of the guest operating systems of the virtual machines106(1)-106(m) to perform the operations on behalf of the guest operatingsystem. In one example, the operating system of the physical device102(1) is configured as a virtual machine manager, shown at referencenumeral 114 in FIG. 1. The virtual machine manager 114 is configured tomanage the virtual machines 106(1)-106(m) and to operate as anintermediary between the virtual machines 106(1)-106(m) and the hardwarecomponents 108 of the physical device 102(1) on which the virtualmachines 106(1)-106(m) are hosted. The virtual machine manager 114 isalso known as a “hypervisor.”

This operation of “taking over” control from the guest operating systemis known as a “trap and emulate” operation. That is, upon trapping theguest operating system, the virtual machine manager 114, itself, willexecute the intended operation by emulating the execution of theoperations in software. Such operations are called “trap-and-emulate”operations that are performed by the virtual machine manager 114. Incertain instances, the virtual machine manager 114 is configured tomonitor and evaluate the code executed in the guest operating systems,and determine whether or not to perform a trap-and-emulate operation.These techniques described in detail hereinafter.

Often times, it is advantageous to implement security techniques toensure that the code of the executed operations in the programs112(1)-112(m) of the virtual machines 106(1)-106(m) (and the programs ofthe physical device 102(1) itself) is secure and unable to be tamperedwith by an outside (e.g., malicious) entity. For example, it may beadvantageous to obfuscate the code of the programs of the virtualmachines such that during static analysis of the code, the logical flowof executed operations would be hidden or otherwise concealed. One knowntechnique of code obfuscation is “control flow obfuscation,” where thelogical sequence of operations of a program code appears as incoherentand/or difficult (if not, impossible) to follow by anoutside/unauthorized entity. These control flow obfuscation techniquescan sufficiently obfuscate the code of a program such that, upon astatic analysis of the code, the outside/unauthorized entity cannoteasily determine the operations and sequence of operations performed bythe program. The difficulty of analysis can be increased (typically atthe detriment of runtime performance) to arbitrary limits, allowing thecost of reverse engineering the code to easily exceed the gains of doingso.

In the virtualization environment, where the virtual machine manager 114performs trap-and-emulate operations, the code of the programs of thevirtual machines can be further obfuscated such that during a staticanalysis of the code, the trap-and-emulate operations themselves aresubverted for non-traditional purposes. That is, in one example, thevirtual machine manager 114 may have prior knowledge and/orsynchronization (e.g., a priori information) with the programs112(1)-112(m) running on the virtual machines 106(1)-106(m). As aresult, the virtual machine manager 114 can monitor the code beingexecuted in order to perform trap-and-emulate operations. For example,the virtual machine manager 114 may detect a trapping event in theexecution of a program's operation, and upon such detection, the virtualmachine manager 114 may perform the trap-and-emulate operation to ensurethat the corresponding operation in the program is executed.

As will become apparent hereinafter, the trapping event may be a typicaltrapping event (e.g., an emulation of a valid operation) or may be anobfuscated or non-traditional trapping event. When the trapping event isa typical trapping event, the trapping event may be events that aretypically always trappable by the virtual machine manager 114 such thatthe virtual machine manager 114 performs a trap-and-emulate operation.When the trapping event is an obfuscated or non-traditional trappingevent, the virtual machine manager 114 may perform a trap-and-emulateoperation that it otherwise would not perform without prior knowledge orsynchronization with the virtual machines 106(1)-106(m). One example ofan obfuscated or non-traditional trapping event is the occurrence of arequest to access a particular memory location of the physical device102(1). The request for access to the particular memory location maytrigger a trap-and-emulate operation to be performed by the virtualmachine manager 114. In this example, a static analysis of the codewould only indicate the request to access the memory location, and thestatic analysis would not reveal that the request to access the memorylocation actually triggered a trap-and-emulate operation performed bythe virtual machine manager. In general, the term “obfuscated trappingevent” or “obfuscated trapping operation” as used herein may be used todifferentiate a trap-and-emulate operation that is used specifically toaffect a non-traditional operation, as opposed to a normal trappingevent which is used for traditional operations. In other words, to anoutside entity, the obfuscated or non-traditional trapping event may notbe easily detectable via a static analysis of the program code. Instead,the static analysis would indicate a normal, functional operation thatmight not otherwise trigger a trap-and-emulate operation by the virtualmachine manager 114, or one that, while triggering a trap-and-emulateoperation, would not ordinarily be associated with the actual eventsthat the obfuscated trapping operation affects. Thus, thetrap-and-emulate operations (e.g., triggered by traditional and/orobfuscated trapping events) performed by the virtual machine manager114, as described by the techniques hereinafter, leads to obfuscation ofthe program code since seemingly operable or executable programoperations that would not otherwise trigger a trap-and-emulate operationnow may do so, or seemingly normal trappable operations take onnon-traditional behaviors. This may result in the virtual machinemanager 114 performing specific operations of a program that differsfrom an operation implied by static analysis of the program.

Reference is now made to FIG. 2. FIG. 2 shows an example oftrap-and-emulate operations 200 performed by the virtual machine 114 inresponse to trapping events (e.g., “trapping operations”). FIG. 2depicts a representation, at 202, of a logical flow associated with aprogram code of one of the virtual machines 106(1)-106(m) (e.g., virtualmachine 106(1)). FIG. 2 also depicts, at 204, a representation oftrap-and-emulate operations performed by the virtual machine manager 114according to the techniques herein. The virtual machine manager 114 alsomaintains a list or database 206 that contains all of the trappingevents in the logical flow 202 of the code. For example, the logicalflow 202 may comprise a series of program operations to be executed, andthe database 206 may contain a list of operations in the code that arenon-traditional or obfuscated trapping events that cause the virtualmachine manager 114 to perform a trap-and-emulate operation.Additionally, the database 206 may contain a list of memory locations(shown as “Memory Location Y” and “Memory Location Z” in FIG. 2) that,upon a request by a program operation, trigger a trap-and-emulateoperation. In other words, the database 206 may contain a list oftrapping events (traditional or obfuscated) themselves and/or maycontain a list of memory locations that trigger trap-and-emulateoperations. Thus, it should be appreciated that the operations depictedin FIG. 2 may trigger trap-and-emulate operations by, for example,requesting access to one or more of the memory locations listed in thedatabase 206.

It should be appreciated that the database 206 may contain onlynon-traditional trapping events, since other trapping events wouldtrigger a trap-and-emulate operation by the virtual machine manager 114regardless. In one example, the database 206 may be implemented by aprocessor and may contain a list of trappable events. Additionalsoftware code may be added to the trappable events (e.g., by the virtualmachine manager 114), and the added software code may differsignificantly from the traditional software assigned to the trappableevents, thus resulting in operations that are not easily ascertainedthrough a static analysis of the program and software code of thetrappable event itself. For example, a program code of one or more ofthe virtual machines 106(1)-106(m) may be supplied a priori to thevirtual machine manager 114, together with the particular obfuscated ornon-traditional trapping events that are present within the programcode. As stated above, the obfuscated or non-traditional trapping eventsmay be operations that otherwise appear as functioning operations duringa static analysis of a program code. Thus, the virtual machine manager114 may need to be “informed” before execution of the program as towhich seemingly functional operations in a program code are actuallyintended to trigger trap-and-emulate operations (e.g., which functionaloperations in a program code are obfuscated trapping events). In oneexample, the programmer of the code may supply this information to thevirtual machine manager 114 a priori (prior to compilation or executionof the program). In FIG. 2, for example, the program code represented bythe logical flow 202 may have been supplied to the virtual machinemanager 114 prior to the program code being compiled or executed, andwhen the program code was supplied to the virtual machine manager 114,an indication may have also been provided to the virtual machine manager114 that Operation B, Operation D and Operation G are intended to betrapping operations (and/or that Memory Location Y and Z are intended totrigger trapping operations upon a request by a program) that triggertrap-and-emulate events. Without this information, the virtual machinemanager 114 may not otherwise be aware that Operation B, Operation D andOperation G are trapping operations and, as a result, may incorrectlyexecute operations without this prior knowledge. Thus, upon receivingthe information about the obfuscated trapping operations within aprogram code, the virtual machine manager 114 can store these trappingoperations in the database of trapping operations 206 and can performthe appropriate trap-and-emulate operations when the program isexecuted.

As shown in FIG. 2, the logical flow 202 lists program operations208(a)-208(x). Operation 208(a) is referred to hereinafter as “OperationA,” operation 208(b) is referred to hereinafter as “Operation B,” and soon. It should be appreciated that operations 208(a)-208(x) may compriseany known or heretofore contemplated program operations that are codedin known programming languages. Operations 208(a)-208(x) may alsocomprise certain logical structures (e.g., “for” loops, “while” loops,link-lists, etc.) that comprise portions of the logical flow 202 of theprogram code. FIG. 2 shows some operations 208(a)-208(x) occurringsequentially (that is, Operation B occurs after Operation A has beenperformed, Operation C occurs after Operation B has been performed, andso on), though it should be appreciated that any order of execution ofthe operations 208(a)-208(x) may be present in the logical flow 202 ofthe code.

As shown in FIG. 2, the database 206 lists Operation B, Operation D andOperation G as trapping events that, upon detection, trigger atrap-and-emulate operation by the virtual machine manager 114. Trappingevents may also be referred to hereinafter as trapping operations.Operation B, Operation D and Operation G are program operations thattrigger a trap-and-emulate operation (e.g., traditional trappingoperations or obfuscated trapping operations that may request access tomemory locations that trigger trap-and-emulate operations). However,accordingly to the techniques herein, since the virtual machine manager114 has prior knowledge of the program code and/or synchronizing withthe virtual machine that runs the program code, the virtual machinemanager 114 is able to specially handle the trap-and-emulatefunctionality associated with these operations. In other words,Operation B, Operation D and Operation G are considered non-traditionalor obfuscated trapping operations/trapping events. Thus, an outsideentity that evaluates the logical flow 202 of the program code would, atbest, not be aware that the program code contains any trappingoperations, or in a worst case would simply dismiss the operations asnormally-handled trap-and-emulate operations.

For simplicity, the program is described herein as being executed by theguest operating system of virtual machine 106(1) and the virtual machinemanager 114 is monitoring execution of the operations shown in thelogical flow 202 of the program code. The program initially points toOperation A for execution. Since Operation A is not a trapping operationlisted in the database 206, the virtual machine 106(1) executesOperation A. The program then points to Operation B. Since Operation Bis a trapping operation (e.g., it is listed in the database 206 oftrapping operations), the virtual machine manager 114, upon detectingOperation B performs a trapping event to take over the operations of theguest operating system of the virtual machine 106(1). As will bedescribed herein after, upon taking over or “trapping” the guestoperating system, the virtual machine manager 114 can emulate OperationB in several ways. For example, the virtual machine manager 114 caninstruct the virtual machine 106(1) to execute Operation B as if therewas no trapping that occurred. Additionally, the virtual machine manager114 can execute Operation B itself and return the result of theoperation to the virtual machine 106(1). It should be appreciated thatthe execution of Operation B upon the trapping may mirror the intendedexecution of Operation B in the logical flow 202 or may be an operationthat is different from the intended execution of Operation B in thelogical flow 202. For example, Operation B may be an “input” operation,and the trap-and-emulate operation for Operation B may also be an“input” operation or may be a different (e.g., a “subtraction”)obfuscated operation. Furthermore, Operation B executed after thetrapping event may be a “null” operation, whereby no operation isperformed.

After the trap-and-emulate operation is performed for Operation B, theresult is returned to the virtual machine 106(1), and the program thenpoints to Operation C. Since Operation C is not a trapping operationlisted in the database 206, the virtual machine 106(1) executesOperation C. The program then points to Operation D. Since Operation Dis a trapping operation (e.g., it is listed in the database 206 oftrapping operations), the virtual machine manager 114, upon detectingOperation D performs a trapping event to take over the operations of theguest operating system of the virtual machine 106(1) in a similar manneras that described for Operation B, above. However, in this example, whenOperation D is emulated by the virtual machine manager 114, the virtualmachine manager 114 returns the result of Operation D to a differentout-of-order execution of operations. This out-of-order execution isshown by Operation X, at 208(x) in the logical flow 202. When the resultof Operation D is returned out-of-order, the program points to OperationX and the virtual machine 106(1) executes it (since it is not in thedatabase 206) and then points to Operation E. This out-of-orderexecution acts as an additional layer of obfuscation. Among otherthings, an outside entity would not be able to glean from a staticanalysis of the program code that (1) Operation D was performed via anon-traditional trap-and-emulate operation and (2) that Operation X wasperformed before Operation E. The out-of-order execution is differentfrom the in-order execution of operations, where the result of atrap-and-emulate operation is returned in sequence. For example,Operation B is returned in-order since upon returning the result of thetrap-and-emulate operation for Operation B, the program points toOperation C.

Continuing further, the program points to Operation E, and sinceOperation E is not a trapping operation listed in the database 206, thevirtual machine 106(1) executes it. The program then points to OperationF and executes it since it also is not in the database 206. Afterwards,the program points to Operation G, which is a trapping operation listedin the database 206. A trap-and-emulate operation for Operation G isperformed by the virtual machine manager, and the result is returned tothe virtual machine 106(1) (e.g., in-order as with Operation B orout-of-order as with Operation D). Thus, as shown in FIG. 2, the virtualmachine manager 114 can trap-and-emulate certain operations of theprogram without the underlying implementation of the trap-and-emulateoperations being revealed in a static analysis of the program code.

FIGS. 3A-3C show example responses from the virtual machine manager 114in response to performing the trap-and-emulate operations. As statedabove, the virtual machine manager 114 is configured to performtrap-and-emulate operations in response to detecting obfuscated ornon-traditional trapping operations in the execution of a program, andthe trap-and-emulate operations can help obfuscate operation of codeunder static analysis as described above. FIGS. 3A-3C show examples ofthe different code obfuscation techniques that may be deployed as partof the trap-and-emulate operations performed by the virtual machinemanager 114. For all of these examples, it should be assumed that thevirtual machine manager 114 has detected an obfuscated or otherwisenon-traditional trapping operation during execution of the code of theprogram.

FIG. 3A shows an obfuscation technique at 302 (e.g., a control flowobfuscation) that is achieved by the virtual machine manager 114 causingthe executed code to jump to a different memory page upon detecting thetrapping operation and performing the trap-and-emulate operation. Forexample, the virtual machine manager 114 will take control of theprogram and will execute the intended operation represented in thetrapping event itself. Upon executing the intended operation, thevirtual machine manager 114 will return control to the program. Forexample, a program may wish to call a subroutine to add two numberstogether (e.g., Operation A in FIG. 3A). The virtual machine manager 114may detect (e.g., through a priori knowledge of the program code) thatthe addition operation is actually an obfuscated/non-traditionaltrapping operation. As a result, the virtual machine manager 114performs a different operation, e.g., subtraction, of the two numbersand modifies the program's environment so that it appears that theoperation has been returned by operation of the code itself. In thisexample, the trapping operation is obfuscated because a static analysisof the program code would show the program as performing a certainoperation (e.g., the adding operation of Operation A) when in fact thevirtual machine manager 114 has performed a completely differentoperation. In one example, the program, using only static analysis,appears to call a subroutine to add two numbers together. The virtualmachine manager 114 has, however, arranged for a trap-and-emulate tooccur at the first instruction of the subroutine being called. Thefunctionality undertaken by the virtual machine manager 114 as part ofthe emulation may then be any arbitrary action (e.g., for simplicity,subtraction of the two numbers, instead of addition). Thus, the targetsubroutine (available to static analysis) is in fact a decoy functionthat is different from the actual intended operation.

FIG. 3B shows another example of code obfuscation at 304 deployed by thevirtual machine manager 114. In FIG. 3B the virtual machine manager 114may detect a trapping event (e.g., an input operation shown as OperationA in FIG. 3B), and upon detecting the trapping event, the virtualmachine manager 114 may take over the program and may instruct thevirtual machine itself to perform the obfuscated operation (e.g.,addition). Upon performing the adding operation, the program code mayhave another trapping event associated with returning the result of theadding operation. Again, the virtual machine manger 114, upon detectingthis trapping event, will take over the program and may either returnthe result itself or may instruct the virtual machine to return theresult. Thus, in this example, the actual operation is being performedby the virtual machine hosting the program itself, and not by thevirtual machine manager.

In another example, a sequence or series of obfuscated trapping eventsmay be present in the program code. The virtual machine manager 114 mayor may not perform the specific operation based on the particularsequence of the obfuscated trapping events. Thus, separate “enabling” or“disabling” trapping events may be embedded in the program code toaffect whether or not subsequent operations are trapped by the virtualmachine manager 114. This priming activity or sequence could be located“far away” from the trappable code sequence. In another example, thevirtual machine manager 114 may keep track of or count a number ofinstances of a predetermined (obfuscated or non-traditional) trappingevent and may perform the specific operation of the program if thenumber of times that the obfuscated trapping event has been detected isgreater than a predetermined threshold number.

FIG. 3C shows an example of a synchronization of trapping events at 306.FIG. 3C may represent a Portable Operating System Interface (POSIX)environment. In the POSIX environment, multiple operations (e.g.,“threads”) may be executed independently. These multiple operations may,however, need to eventually synchronize at a “barrier” before anotheroperation is performed. For example, as shown in FIG. 3C, Operations A,B, C and D may be performed independently (e.g., by independent cores ofa quad-core processor), but before Operation E is performed, OperationsA-D need to be synchronized with each other. In one example, all of theOperations A-D are obfuscated trapping operations, and one of theoperations in particular may be a different obfuscated trappingoperation from the others. The virtual machine manager 114 takes overthe program to perform the trap-and-emulate operations for each one ofthe Operations A-D, but only one is designated as a “master” operation(e.g., Operation D in FIG. 3C). The master operation synchronizes theseries of operations with respect to it such that all of the operationsare performed before the operation at the barrier (Operation E) isperformed.

Reference is now made to FIG. 4. FIG. 4 shows a flow chart 400 thatdepicts a sequence of operations that trigger the trap-and-emulateoperations performed by the virtual machine manager 114. At referencenumeral 402, a program configured to execute one or more operations isrun on a virtual machine. At reference numeral 404, the virtual machinemanager 114 monitors execution of the program to detect an obfuscatedtrapping event that causes the virtual machine manager to take overoperation of the program. At operation 406, upon detecting theobfuscated trapping event, the specific operation of the program isperformed. As described above, this operation may be performed by thevirtual machine manager 114 or by the virtual machine hosting theprogram. Also, as described above, the specific operation of the programmay be performed such that the operation performed differs from anoperation implied by static analysis of the program.

Reference is now made to FIG. 5, which shows an example block diagram ofthe physical device with software configured to perform obfuscationtechniques. The physical device in FIG. 5 is shown at reference numeral102, though it should be appreciated that the physical device 102 mayrepresent any of the physical devices in FIG. 1. Physical device 102comprises, among other units, a network interface unit 502, a processor504 and a memory 506.

The network interface unit 502 is configured to send and receivecommunications (e.g., data packets and other communications) to devicesin the system 100. The processor 504 is, for example, a microprocessoror microcontroller that is configured to execute program logicinstructions (i.e., software) for carrying out various operations andtasks of the physical device 102, as described herein. For example, theprocessor 504 is configured to execute the code obfuscation software 508in the memory 506 to obfuscate the operations of the code of programs.The functions of the processor 504 may be implemented by logic encodedin one or more tangible computer readable storage media or devices(e.g., storage devices compact discs, digital video discs, flash memorydrives, etc. and embedded logic such as an application specificintegrated circuit, digital signal processor instructions, software thatis executed by a processor, etc.).

The memory 506 may comprise read only memory (ROM), random access memory(RAM), magnetic disk storage media devices, optical storage mediadevices, flash memory devices, electrical, optical, or otherphysical/tangible (non-transitory) memory storage devices. The memory506 stores instructions for the code obfuscation software 508. Thus, ingeneral, the memory 506 may comprise one or more computer readablestorage media (e.g., a memory storage device) encoded with softwarecomprising computer executable instructions and when the software isexecuted (e.g., by the processor 502) it is operable to perform theoperations described herein.

The memory 506 also stores the virtual machine manager 114 and one ormore virtual machines 106(1)-106(m). As described above, the virtualmachine manager 114 is configured to manage the virtual machines106(1)-106(m) and is configured to perform trap-and-emulate operations,as described herein. The virtual machines 106(1)-106(m) are configuredto run programs 112(1)-112(m).

The code obfuscation software 508 may take any of a variety of forms, soas to be encoded in one or more tangible computer readable memory mediaor storage device for execution, such as fixed logic or programmablelogic (e.g., software/computer instructions executed by a processor),and the processor 502 may be an application specific integrated circuit(ASIC) that comprises fixed digital logic, or a combination thereof.

In still another example, the processor 502 may be embodied by digitallogic gates in a fixed or programmable digital logic integrated circuit,which digital logic gates are configured to execute the code obfuscationsoftware 508. In general, the code obfuscation software 508 may beembodied in one or more computer readable storage media encoded withsoftware comprising computer executable instructions and when thesoftware is executed operable to perform the operations described above.

It should be appreciated that the techniques described above inconnection with all embodiments may be performed by one or more computerreadable storage media that is encoded with software comprising computerexecutable instructions to perform the methods and steps describedherein. For example, the operations performed by the physical device 102may be performed by one or more computer or machine readable storagemedia (e.g., non-transitory) or device executed by a processor andcomprising software, hardware or a combination of software and hardwareto perform the techniques described herein.

In summary, a method is provided comprising: on a virtual machine hostedby a physical device, running a program configured to execute one ormore operations; at a virtual machine manager hosted by the physicaldevice and configured to manage the virtual machine, monitoringexecution of the program to detect a trapping event that causes thevirtual machine manager to take over operation of the program; and upondetecting at the virtual machine manager the trapping event, performinga specific operation of the program that differs from an operationimplied by static analysis of the program.

In addition, one or more computer readable storage media is providedthat is encoded with software comprising computer executableinstructions and when the software is executed operable to: run aprogram configured to execute one or more operations; monitor executionof the program to detect a trapping event that causes a virtual machinemanager to take over operation of the program; and upon detecting at thevirtual machine manager the trapping event, perform a specific operationof the program that differs from an operation implied by static analysisof the program.

Furthermore, an apparatus is provided comprising: a network interfaceunit; a memory; and a processor coupled to the network interface unitand the memory and configured to: run a program configured to executeone or more operations; monitor execution of the program to detect atrapping event that causes a virtual machine manager to take overoperation of the program; and upon detecting at the virtual machinemanager the trapping event, perform a specific operation of the programthat differs from an operation implied by static analysis of theprogram.

The above description is intended by way of example only.

What is claimed is:
 1. A method comprising: on a virtual machine hostedby a physical device, running a program configured to execute one ormore operations; at a virtual machine manager hosted by the physicaldevice and configured to manage the virtual machine, monitoringexecution of the program to detect an obfuscated trapping event thatcauses the virtual machine manager to take over operation of theprogram; and upon detecting at the virtual machine manager theobfuscated trapping event, performing, by the virtual machine manager, aspecific operation that differs from an operation implied by staticanalysis of the program, wherein the virtual machine manager maintains alist of operations of the program that correlate with obfuscatedtrapping events, wherein the specific operation is known to the virtualmachine manager prior to the program being executed and wherein thespecific operation is an operation that the virtual machine managerwould not otherwise perform as a result of executing the program.
 2. Themethod of claim 1, wherein performing comprises, at the virtual machinemanager, taking control of the program to perform the specificoperation.
 3. The method of claim 1, further comprising, performing thespecific operation in an out-of-order execution sequence of operationsof the program.
 4. The method of claim 1, further comprising, performingthe specific operation in an in-order execution sequence of operationsof the program.
 5. The method of claim 1, wherein performing comprises,at the virtual machine manager, taking control of the program to performthe specific operation such that it appears that the specific operationis performed by the virtual machine.
 6. The method of claim 1, furthercomprising: keeping track of a number of instances of a predeterminedtrapping events; and performing the specific operation of the program ifthe number of instances that one or more of the predetermined trappingevents matches a certain pattern known to the virtual machine manager.7. The method of claim 1, wherein performing comprises: at the virtualmachine manager, taking control of the program to perform the specificoperation; and performing the specific operation so that it appears thatan operation different from the specific operation is performed.
 8. Themethod of claim 1, further comprising: at the virtual machine manager,monitoring execution of the program to detect a series of trappingevents corresponding to a series of threads; and controlling executionof the threads based on a known sequence of trapping events.
 9. Themethod of claim 1, further comprising: at the virtual machine manager,monitoring execution of the program to detect a sequence of trappingevents; and determining from the sequence of trapping events whether ornot to perform the specific operation.
 10. The method of claim 1,wherein monitoring comprises monitoring execution of the program todetect the obfuscated trapping event that requests access to aparticular memory location known to the virtual machine manager astriggering a trap-and-emulate operation.
 11. One or more non-transitorycomputer readable storage media encoded with software comprisingcomputer executable instructions and when the software is executedoperable to: run a program configured to execute one or more operations;monitor execution of the program to detect an obfuscated trapping eventthat causes a virtual machine manager to take over operation of theprogram; and upon detecting at the virtual machine manager theobfuscated trapping event, perform, by the virtual machine manager, aspecific operation that differs from an operation implied by staticanalysis of the program, wherein the virtual machine manager maintains alist of operations of the program that correlate with obfuscatedtrapping events, wherein the specific operation is known to the virtualmachine manager prior to the program being executed and wherein thespecific operation is an operation that the virtual machine managerwould not otherwise perform as a result of executing the program. 12.The non-transitory computer readable storage media of claim 11, whereinthe instructions operable to perform the specific operation of theprogram comprise instructions operable to take control, at the virtualmachine manager, of the program to perform the specific operation. 13.The non-transitory computer readable storage media of claim 12, furthercomprising instructions operable to perform, at the virtual machine, thespecific operation in an out-of-order execution sequence of operationsupon receiving the instruction from the virtual machine manager.
 14. Thenon-transitory computer readable storage media of claim 12, furthercomprising instructions operable to perform, at the virtual machine, thespecific operation in an in-order execution sequence of operations uponreceiving the instructions from the virtual machine manager.
 15. Thenon-transitory computer readable storage media of claim 11, wherein theinstructions operable to perform the specific operation of the programcomprise instructions operable to take control, at the virtual machinemanager, of the program to perform the specific operation such that itappears that the specific operation is performed by the virtual machine.16. An apparatus comprising: a network interface unit; a memory; and aprocessor coupled to the network interface unit and the memory andconfigured to: run a program configured to execute one or moreoperations; monitor execution of the program to detect an obfuscatedtrapping event that causes a virtual machine manager to take overoperation of the program; and upon detecting at the virtual machinemanager the obfuscated trapping event, perform, by the virtual machinemanager, a specific operation that differs from an operation implied bystatic analysis of the program, wherein the virtual machine managermaintains a list of operations of the program that correlate withobfuscated trapping events, wherein the specific operation is known tothe virtual machine manager prior to the program being executed andwherein the specific operation is an operation that the virtual machinemanager would not otherwise perform as a result of executing theprogram.
 17. The apparatus of claim 16, wherein the processor is furtherconfigured to keep track of a number of instances of a predeterminedtrapping events; and perform the specific operation of the program ifthe number of instances that one or more of the predetermined trappingevents matches a certain pattern known to the virtual machine manager.18. The apparatus of claim 16, wherein the processor is furtherconfigured to monitor execution of the program to detect the obfuscatedtrapping event that requests to a particular memory location known tothe virtual machine manager.